When Ionisis develops products that will be used in the context of software as a service, we do not use contemporary "software versions", as this does not fit well with a delivery methodology that is centered around a live work in progress, which is another distinguishing factor of SaaS.

Ionisis has the standard software that users have access to, and then we sometimes have a beta version, that is primarily for developer use. Once the beta version comes far enough along, it replaces the live, or "production" version. In case there is any serious issues that were over looked, the previous production version is moved to what we then call a "Legacy Version", until we can be certain that the new production version is stable and secure enough that we would not have to revert back to the legacy version. By not maintaining versions, we eliminate a lot of development overhead, and have a faster project development time, and a faster new features release time.

With SaaS oriented software developed by Ionisis, there are no real "updates", as the live production product is continually "enhanced" to fix bugs, or to add new features and functionality. This is almost always done on the live version, and not a beta version.

Beta versions to SaaS products are typically reserved for dramatic changes to the software's functionality, that sometimes reach all the way down to its core components. One such example would be the migration of some of the software systems to AJAX. Such a change is a radical enough not to be practicable to attempt to implement on the live production version.

After the beta version of the SaaS software is far enough along in progress, one of two things can happen, depending on the nature of the software and its users' needs. One typical outcome would be that the old version is moved to "legacy" status temporarily, until the new version can be assumed to be stable and secure enough, and then the legacy version is done away with. The other outcome would be that the legacy version is retained and maintained for compatibility purposes. In the case of the AJAX example, this would be to accommodate users who do not have javascript installed or enabled, or iPhone users who can view a full website without the explicit need for a mobile version, but yet would still benefit from a non-AJAX version.